[01:17.840 --> 01:22.160]  Okay, I'm Jeremiah Grossman. This is Lex Arquette. We're going to be doing a talk on web application
[01:22.160 --> 01:30.820]  security. Thank you. This talk is going to be different from the one we did last year.
[01:30.820 --> 01:34.960]  There's going to be a lot more exploit theory and a lot more exploits and how to beat different
[01:34.960 --> 01:42.480]  CGI filters. Things that every CGI application is going to be exposed to, if not now, later.
[01:42.480 --> 01:49.420]  So, let's just start. A lot to cover. What is web application security? Simple enough,
[01:49.420 --> 01:55.680]  it's the securing of web applications. It's pretty simple. Web applications, they're used
[01:55.680 --> 01:59.480]  everywhere, you know, they transfer money within bank accounts, you know, message boards,
[01:59.480 --> 02:06.440]  web mail, I mean, you name it, there's a web application for it. And the security that
[02:06.440 --> 02:09.220]  we're going to be showing applies to them all because they're all taking user input
[02:09.220 --> 02:15.440]  and sit between a web server with a web interface. Anything that does that, anything that processes
[02:15.440 --> 02:22.320]  via a web server is a CGI and this is what we're going to be covering. The difference
[02:22.320 --> 02:26.760]  between software programming, at least from a security standpoint, is different from the
[02:26.760 --> 02:33.020]  way that before when you wrote an application, you know, on a LAN or, you know, maybe like
[02:33.020 --> 02:38.960]  ten years ago, the application that you write, the user base is relatively small. So, you
[02:38.960 --> 02:43.400]  didn't see as much abuse of the applications that you do now. Now, when a web developer
[02:43.400 --> 02:48.280]  or any kind of software engineer writes a program that's shipped via the web, everybody
[02:48.280 --> 02:52.840]  has access to it and there's going to be some people, a thousand people, they're going to
[02:52.840 --> 02:58.340]  have an infinite amount of time to mess it up, you know, throw whatever they can at it
[02:58.340 --> 03:03.560]  to make it screw up or do whatever they feel. So, some of the attacks when we're talking
[03:03.560 --> 03:08.700]  about web application security is browser hijacking, which means is an attacker threw
[03:08.720 --> 03:12.960]  a web page on the client side. It's important to realize what client side is when we talk
[03:12.960 --> 03:20.960]  about it. Client side is like when you're viewing a web page, somebody injects JavaScript
[03:20.960 --> 03:24.820]  via like a message board or something and takes control over your browser. Client side
[03:24.820 --> 03:29.400]  through like document dot location or closes your window and a million different abuses
[03:29.400 --> 03:32.960]  like that. There's also cookie theft and we'll get into cookie theft in a minute. There's
[03:32.960 --> 03:39.840]  server and client side compromise, shipping weird characters and input validation manipulation
[03:40.520 --> 03:45.480]  to get the server to give up more than it should or more access than it should. There's
[03:45.480 --> 03:51.920]  also denial of service where creativity within a web application exploit, you can actually
[03:51.920 --> 03:56.460]  render a site useless by no one is allowed to get there. Every time they go there, they're
[03:56.460 --> 04:02.020]  pushed away. There's also different abuse mechanisms like cheating on games or cheating
[04:02.020 --> 04:10.580]  on auctions or buying a laptop for $20 where you should have paid $2,000. And there's also
[04:10.580 --> 04:15.660]  user privacy invasion. The client side scripting applications give you tremendous amount of
[04:15.660 --> 04:22.900]  power and information about the user of which they execute. You'll get IP addresses, host
[04:22.900 --> 04:27.900]  names, subnets, user names, email addresses, system configurations, you name it. There's
[04:27.900 --> 04:36.540]  all kinds of data you can access with a client side script. So, let's get right to it. How
[04:36.540 --> 04:42.400]  to steal cookies because it seems like many people aren't too sure how it's done. Cookies
[04:42.400 --> 04:46.300]  are, the cookie security is, you know, according to the RFCs and different documentation you
[04:46.300 --> 04:51.040]  might read, they're restricted to domains. So when a cookie is set within a client, there
[04:51.040 --> 04:56.180]  is a domain that is attached to the cookie which the client should only send the cookie
[04:56.180 --> 05:03.040]  back to cookies within that domain. Cookies bleeding over into another domain is considered
[05:03.040 --> 05:09.860]  not good and that's a cookie theft and can lead to all types of user compromise. Basically
[05:09.860 --> 05:15.400]  how a cookie is stolen is by somebody injecting JavaScript or some kind of cookie thieving
[05:16.740 --> 05:21.800]  tool onto the domain that steals a cookie. So basically if you're a web administrator,
[05:21.800 --> 05:26.840]  you do not want to have uncontrolled web data on your domain or at least on a protected
[05:26.840 --> 05:31.320]  domain. So, I just use JavaScript, you know, you can do the same thing with VB scripts
[05:31.320 --> 05:35.680]  and a lot of other, you know, web application scripting languages. But we have the expression
[05:35.680 --> 05:41.860]  document.cookie. Basically that's just a string of the cookie data of the domain of which
[05:41.860 --> 05:47.860]  the script is executed on. Now what you can do here is with these following functions
[05:47.860 --> 05:55.380]  like window.open, document.image.source, you set window.open equals to attacker.com.cgi.bin
[05:55.380 --> 06:03.820]  pointed at your CGI and append the cookie data to it. What happens is the cookie data
[06:03.820 --> 06:08.540]  actually gets passed over a get connection or an HTTP post or get or whatever and you
[06:08.540 --> 06:12.580]  can actually pick it up off domain. So you're basically just moving strings around and using
[06:12.580 --> 06:16.600]  the power of HTML and JavaScript to move the cookie off the domain. So there's lots of
[06:16.600 --> 06:20.500]  ways to do it. You know, I've written utilities on it, but I've been hesitant to do it recently
[06:20.500 --> 06:22.660]  because I don't feel like a bunch of script kiddies need to be running around stealing
[06:22.660 --> 06:31.270]  everybody else's cookies. So, what are secure web programming practices? You'll hear this
[06:31.390 --> 06:37.150]  a lot. Do not trust client-side data. You'll understand more why later, but as a whole,
[06:37.150 --> 06:41.670]  you cannot trust anything coming from a client. You have to validate it, you have to sanity
[06:41.670 --> 06:49.810]  check it. You do not trust it. There's also hidden form elements are not hidden. If you
[06:49.810 --> 06:57.590]  put a price inside of like an online order form, they're not hidden. These are just common
[06:57.590 --> 07:01.730]  things that we see around. Password elements, still transferring clear text, just because
[07:01.730 --> 07:06.070]  you can't see it doesn't mean it's encrypted or anything. Use solid crypto when you're
[07:06.070 --> 07:11.930]  doing anything online. Don't use DoubleRot13, no matter how secure your friend thinks it
[07:11.930 --> 07:17.930]  is. Of course, stick to DES, triple DES, Blowfish, there's lots of good ones out there, but stick
[07:17.930 --> 07:23.830]  to the ones you know that have been proven. Avoid authentication mechanisms using JavaScript.
[07:25.750 --> 07:30.090]  Basically everything happens client-side using authentication via JavaScript, all the passwords
[07:30.090 --> 07:36.710]  or at least all the authentication credentials are going to be at your fingertips. Re-authenticate
[07:37.430 --> 07:41.650]  the user with a password before issuing new passwords, you know, just goes right towards
[07:41.650 --> 07:44.950]  like the Unix mindset, you know, they have to type in their own password before you issue
[07:44.950 --> 07:48.750]  new ones. You'd be surprised or maybe not so surprised how many sites allow you to change
[07:48.750 --> 07:53.170]  password just by manipulating some of the input fields to change a password once you have
[07:53.250 --> 08:01.950]  a stolen cookie. Let's see. Do not host uncontrolled data on a protected domain. I realize for
[08:01.950 --> 08:08.030]  some people doing this is hard, but as a general rule, try not to do this. Sanity check and
[08:08.030 --> 08:16.210]  qualify all incoming data and another great resource is the World Wide Web Security FAQ,
[08:16.210 --> 08:20.830]  if you haven't read it already. By the way, all this material will be available on whitehatsec.com
[08:20.830 --> 08:28.570]  probably Monday when we get home. These are the basic client-side scripting languages.
[08:30.570 --> 08:36.990]  There are a lot of them. This is not a finite list. There are more. We have DHTML, JavaScript,
[08:36.990 --> 08:45.070]  Java, Applets, VBScript, Flash, ActiveX, XML, and XSL. Getting to XML, most people are using
[08:45.070 --> 08:49.810]  on the backside right now. However, browsers are supporting it on the client side and when
[08:49.810 --> 08:56.110]  you get to some of the security issues about XML and XSL and Microsoft.net at the end.
[08:56.250 --> 09:02.750]  And there's also CSS. We have the document object model. Basically, this is like the
[09:02.750 --> 09:09.290]  object-oriented model for HTML and JavaScript to access different functions and features
[09:09.950 --> 09:16.250]  and information within the browser. Basically, with all these client-side scripting languages,
[09:16.250 --> 09:20.510]  all their complexities, all the different things they can do can be combined to gain
[09:20.510 --> 09:27.810]  increased access to the DOM, which they really shouldn't. Basically, you can get background
[09:27.810 --> 09:37.660]  colors, you can get files, and you can even execute system calls. Okay, if you're running
[09:37.760 --> 09:42.180]  a web application, or at least with some kind of complexity, you're going to be taking input
[09:42.180 --> 09:48.480]  from the user. So again, never trust client-side data. Escape, validate, parse, filter, and
[09:48.480 --> 09:54.080]  sanity check all data. All of it. Not just like the ones where they're typing in like
[09:54.200 --> 10:01.660]  a search field. Get the hidden ones. Everything coming over has to be checked. With client-side
[10:01.660 --> 10:07.040]  data, you can never be too paranoid. Let your paranoia be your guide. Let's see, common
[10:07.040 --> 10:15.980]  input. Mistakes. Sanity check all input. When I say sanity checking, a lot of CGI's that
[10:15.980 --> 10:21.880]  we find, like, for instance, the yes or no, we find that a lot of times, you know, the
[10:21.880 --> 10:27.080]  pull-down menu says yes or no, but we can actually add like a nothing or some other
[10:27.080 --> 10:32.480]  string in there to cause panic within or an error within the web application. So for instance,
[10:32.480 --> 10:38.180]  if you're using a numeric value or a yes or no, check the input for what you're expecting
[10:38.180 --> 10:44.060]  and ditch the rest. Escape it. Don't be just taking in whatever you want or whatever they
[10:44.060 --> 10:49.740]  send to you. Same goes for file names, paths. Don't parse and especially don't use what
[10:49.740 --> 11:00.620]  you don't know. Escape all input special characters. So it's important to understand that special
[11:00.620 --> 11:03.360]  characters have a lot of meanings on a lot of different operating systems where it's
[11:03.360 --> 11:10.380]  piping, redirecting, semi-colons, stars, file-globbing. Special characters can do a lot to your system
[11:10.380 --> 11:16.720]  so they all have to be escaped or replaced or something has to happen to them. Preferably,
[11:16.720 --> 11:21.540]  if you need to use special characters, escape them. If you don't, remove them. And null
[11:21.540 --> 11:25.540]  characters is very important. Null characters don't belong in, should not come over the
[11:25.540 --> 11:32.140]  wire unless there are some really weird circumstances, but they all should be ripped out completely.
[11:35.290 --> 11:42.160]  If you have need to allow HTML into your site, however it's not supposed to execute, use
[11:42.160 --> 11:46.760]  these little guidelines so it doesn't. Basically, you just want to convert the less than and
[11:46.760 --> 11:51.000]  greater than signs and the quotes into HTML entities. It's real simple, very important
[11:51.000 --> 12:00.240]  though. Everything from file not founds to search fields to search errors. A few other
[12:00.240 --> 12:06.020]  things that you got to watch out for, you know, the directory transversals, the file-globbing,
[12:06.020 --> 12:12.780]  appending commands. We find a lot of times registering for, for instance, like a mailing
[12:12.780 --> 12:15.800]  list or something, you type in your email address and it auto-responds, it'll just do
[12:15.900 --> 12:21.020]  a quick send mail, send mail to this email address. Well, pipe a semi-colon on and execute
[12:21.020 --> 12:30.220]  another command, cat direct etc password and you got it. Data piping, quotes are, quotes
[12:30.240 --> 12:35.500]  can do a lot of damage, especially when you're using fixed strings like in a sequel and things
[12:35.500 --> 12:42.540]  like that. So if you're not wanting these, you know, strip them out or escape them. Output
[12:42.540 --> 12:49.760]  filtering a lot of times is ignored. Output filter queries from a database, for instance,
[12:49.760 --> 12:55.260]  somebody might be updating their profile information and put a lot of nice, a lot of little cool
[12:55.260 --> 13:00.220]  HTML and stuff and they go, hey, see my profile. So, does a query, ships it back to the person
[13:00.220 --> 13:05.220]  that saw and there's XML or HTML executing on the client side. So you have to output
[13:05.220 --> 13:10.540]  filter as well as input filter. And if you want to take a quick note, here's some other
[13:10.540 --> 13:16.080]  good CGI examples that give a lot of, a lot of really good data.
[13:19.250 --> 13:24.290]  HTML is dangerous. You know, it's, you know, it seems light, loose, everybody uses it,
[13:24.290 --> 13:30.610]  but it is dangerous, especially for web applications or client side security. If your system, if
[13:30.610 --> 13:36.410]  it's web mail, message boards or whatever, if it's using HTML input from users, it's
[13:36.410 --> 13:40.970]  very hard to get it secure. Even when the proper precautions are taken, it's very hard
[13:40.970 --> 13:47.530]  to lock it down. So the best way I could suggest to lock it down is use allow permit lists.
[13:47.950 --> 13:54.390]  Know what HTML you want your users to be able to send in and only allow those. This goes
[13:54.390 --> 14:02.650]  for attributes too. Also, let's see. Yeah, limit your lists, keep them short, know what
[14:02.650 --> 14:07.390]  they are, and know what attributes and tags are harmful so you don't put them on your
[14:07.390 --> 14:12.410]  allow list. We'll get to the list in a second. Well, there it is. So these are the common
[14:12.410 --> 14:18.470]  tags that are known to be dangerous for various reasons. Applet, you can input Java and gain
[14:18.570 --> 14:23.310]  a lot of access. Image, inline images can grab cookies. Layers, you can source in other
[14:23.310 --> 14:32.550]  data. You know, object, ActiveX controls. Style and script are pretty self-explanatory.
[14:33.030 --> 14:39.130]  But these are basically the tags that are known to be dangerous that every system allowing
[14:39.130 --> 14:46.230]  HTML has danger inherent when they are allowing these tags. Any tags with attributes that
[14:46.230 --> 14:50.350]  have style, source, href, or type are also at risk. So you have to watch out for these
[14:50.350 --> 14:58.050]  attributes in any tag that allows them. Now we're going to get a bit into user authentication.
[15:04.650 --> 15:08.330]  Web applications a lot of times have need to authenticate the user, whether it's username
[15:08.330 --> 15:13.150]  and password or persistent cookies and that nature. So we're going to get... go into a
[15:13.150 --> 15:18.590]  lot of things in that nature that we see out there. And some guidelines to help out people
[15:18.590 --> 15:23.430]  so they know what to do and what not to do. Passwords, as a general rule, are your user's
[15:23.430 --> 15:28.450]  weakest link. Users are always picking easy passwords. Users are always giving up their
[15:28.450 --> 15:34.550]  passwords. So, never store passwords in plain text. Age all passwords. It's very important
[15:34.550 --> 15:42.010]  that passwords, at least at a given amount of time, they die or they invalidate themselves.
[15:42.010 --> 15:47.010]  Age all passwords. Otherwise, make sure good system maintenance. So you don't have a password
[15:47.010 --> 15:51.050]  that's on the system for about, you know, six years and you forgot about and somebody
[15:51.050 --> 15:56.690]  can still log in or steal it. Age them and deny them. Password restrictions, we'll get
[15:56.690 --> 16:02.930]  to that next. General guidelines. Passwords should be, at least in my opinion, should
[16:02.930 --> 16:10.150]  be six letters in length. Six letters in length. Not matching the username. And not a common
[16:10.150 --> 16:14.070]  password and contains one capital letter. It's a very simple password, but however,
[16:14.070 --> 16:19.450]  it gets a decent amount of security. Now, a lot of usability experts and security people
[16:19.450 --> 16:26.510]  have different mindsets on it as far as usability versus security. This should, for the most
[16:26.510 --> 16:31.810]  part, secure your passwords to at least a minimum level. You know, it's better than
[16:31.810 --> 16:36.390]  password being password. If they have to have password as their password, make it a capital
[16:36.390 --> 16:44.010]  P with a 1 at the end. Passwords should be six letters in length. For an increased security,
[16:44.010 --> 16:47.890]  passwords should be six letters in length, not matching the username or part of it. Not
[16:47.990 --> 16:51.790]  a common password and must contain one capital and one special character. This is pretty
[16:51.790 --> 16:55.970]  good. This would be pretty hard to crack, at least on a brute force level on a web basis.
[16:56.830 --> 17:02.830]  Again, let your paranoia be your guide. What not to do. Now, we see this out there a lot.
[17:03.490 --> 17:09.130]  Placing a maximum password length. Okay, don't do that. I've seen places where they're allowing
[17:09.130 --> 17:15.950]  like, you know, no passwords over 4 or 5 characters. Now, how long does that take to crack? Passwords
[17:15.950 --> 17:19.930]  that are allowed to be changed into the old ones. So, let's say you're doing aging. Don't
[17:19.930 --> 17:28.600]  let your users change their password into the current password. Check for that. A lot
[17:28.600 --> 17:32.200]  of sites we've seen, well, maybe not a lot, but it does happen, echo the new password
[17:32.200 --> 17:38.140]  that they typed in over a non-SSL link. No need for sniffer bait. Password restrictions
[17:38.140 --> 17:42.160]  are too high. This is kind of like a sticky point. You can make your password restrictions
[17:42.160 --> 17:46.120]  pretty high for, you know, most competent users. But if you make them like too high,
[17:46.120 --> 17:56.250]  like, you know, really, really high. Both. These are like general guides. You can actually
[17:56.250 --> 18:04.290]  adapt these to a lot of secure programming. Making password restrictions too high. What
[18:04.290 --> 18:07.170]  happens if you make a password too high? You know, they're typing upper and lower case
[18:07.170 --> 18:11.450]  and numbers and symbols and stuff. Users are, at least on like a web sense when you're dealing
[18:11.450 --> 18:15.690]  with like a, you know, 50 million users or 30 million users or what have you. They're
[18:15.690 --> 18:18.910]  going to write down their password and stick it on a sticky note and put it on their monitor.
[18:19.190 --> 18:24.010]  So, you know, so you have to walk that line. You want to make it secure, yes, but not too
[18:24.010 --> 18:30.630]  secure where they're tempted to do stupid things. Okay, brute force attacks. We're going
[18:30.630 --> 18:33.250]  to go real quick over this because this is Uber Hacker. You guys should be all aware
[18:33.250 --> 18:39.270]  of this stuff. Brute force in a web account, web accounts, there's two main attacks, at
[18:39.270 --> 18:42.710]  least from like a web sense, for instance, like, you know, banking and stuff like that.
[18:42.710 --> 18:49.110]  One user name against many passwords or less common but very effective, one password against
[18:49.110 --> 18:52.870]  many usernames. So some systems, if they don't have password restrictions, pick the password
[18:52.870 --> 18:58.470]  password and level it against 1,000 user accounts and you're probably going to crack a couple.
[18:59.390 --> 19:05.910]  Each attack can be very effective and both must be defended against. We're going to state
[19:05.910 --> 19:11.070]  some defense mechanisms against it. So how do you defend your web apps against brute
[19:11.070 --> 19:16.230]  force? Set an acceptable threshold of the amount of failed attempts a single account
[19:16.230 --> 19:20.550]  can receive before that offender is blocked at an IP level, because you don't want to
[19:20.550 --> 19:26.130]  keep doing it, and the account itself is locked. Same thing goes for multiple accounts from
[19:26.130 --> 19:31.730]  the same IP. Okay, when an IP set, you know, goes over like 10 failed attempts, you have
[19:31.730 --> 19:36.410]  to block them. Okay, so for instance, like on the reverse brute force, a single account
[19:36.410 --> 19:43.590]  isn't going to get like 10 attempts. 10 attempts, however, you still want to block the IP. Now
[19:43.670 --> 19:46.970]  a lot of people are thinking like, you know, wait a minute, there's like DOS attacks regarding
[19:46.970 --> 19:52.130]  this, right? Like, for instance, if, you know, somebody's, two people are competing at an
[19:52.130 --> 19:55.810]  auction, you know, and I want to win, so I'm going to lock my opponent's account so he
[19:55.810 --> 20:01.810]  can't make a bid. So where to get to the point? Did you guys get that? I'll say that one more
[20:01.810 --> 20:06.850]  time. So let's say I'm, you know, I like this Dell laptop and I want to get another,
[20:06.850 --> 20:11.350]  so I log on to my favorite auction, and there's a bid war, you know, going up and up and up
[20:11.350 --> 20:18.130]  and up, and I'm sick of having to, you know, bid-bask my opponent. So what I do is, I sent,
[20:18.130 --> 20:24.170]  I knowingly send 10 failed attempts against his account, and now he can't bid, and I win.
[20:24.170 --> 20:36.910]  So, however, like, one second, yes please. He asked about proxied users, we'll get to
[20:36.910 --> 20:45.750]  that in a second. Okay. So, now, there's DOS attacks against these systems, as I just said.
[20:45.950 --> 20:49.730]  Basically if an attacker wanted to DOS an account, he could, because he doesn't really
[20:49.730 --> 20:53.350]  care about cracking the account, he just wants to block the user, many abuses in this regard.
[20:53.830 --> 21:00.190]  Now, also as a result from IP blocking, AOL and proxied users are blocked also, because
[21:00.190 --> 21:04.630]  they're amassed behind like a single subnet. Know your users. If you're in a restricted
[21:04.630 --> 21:12.550]  environment, you can IP block without restriction. However, if you're, like, servicing the entire
[21:12.550 --> 21:17.270]  web, you're going to have to make allowances for proxy users and AOL users, so, you know,
[21:17.270 --> 21:22.490]  basically, you can't block AOL. So, basically, you just have to set the rules, then, that
[21:22.490 --> 21:32.050]  you can't block AOL. Bummer! Possible solutions. When blocking an account, log the offending
[21:32.050 --> 21:36.930]  IP with the account block. Now, what happens is, if the legitimate user logs on to the
[21:36.930 --> 21:41.730]  account, and the system is going, okay, this account's blocked, but I want to take, I want
[21:41.730 --> 21:47.370]  to do a comparison against the new requesting IP and the one that was the original offending
[21:47.370 --> 21:50.490]  one. If they don't match, and if they get the password right, let's say in, like, three
[21:50.490 --> 21:53.610]  attempts, you can allow them. However, if they get it wrong over three attempts, then
[21:53.610 --> 21:57.790]  you can block them, too. So, basically, these are some of the solutions against the DOS
[21:57.790 --> 22:04.930]  attacks, against these types of anti-brute force mechanisms. Okay, we're going to get
[22:04.930 --> 22:14.490]  to cookie authentication. Cookies, everyone knows, this is UberEcker again, that cookies
[22:14.490 --> 22:18.370]  are used a lot of times for authentication, you know, maybe not htaccess or something
[22:18.370 --> 22:23.030]  like that, but cookies are used for authentication. Now, we're not going to get into all the different
[22:23.030 --> 22:26.730]  kind of ways people are doing the authentication, but we're going to show you some of the basic
[22:26.730 --> 22:31.450]  steps on how to increase the security of your cookie authentication that you're already
[22:31.450 --> 22:37.630]  using. Use SSL for, these are very simple, use SSL for username and passwords, again,
[22:37.630 --> 22:41.710]  no need for sniffer bait. Don't store plain text passwords or weakly encrypted passwords
[22:41.710 --> 22:48.010]  in a cookie. Again, don't use ROT13 for passwords in cookies, that's very bad. Cookies are going
[22:48.010 --> 22:52.390]  to get stolen. Now, there are just far too many ways this is going to happen, so you
[22:52.390 --> 22:56.310]  have to remember this, cookies are going to get stolen, okay? You know, there's plenty
[22:56.310 --> 23:01.210]  of IE bugs, there's plenty of cross-scripting exploits, cookies are going to get stolen.
[23:01.810 --> 23:06.830]  It's too bad, it's sad, but it's going to happen. Now, if a cookie is compromised, two
[23:06.830 --> 23:11.310]  things should not happen. The cookie should not be able to be reused or reused easily
[23:11.310 --> 23:16.430]  by another person on another computer. The password should not, information from the
[23:16.430 --> 23:21.550]  password should not be extracted that's confidential, okay? That's two very important things. If
[23:21.650 --> 23:27.550]  a cookie is to be compromised, those two things should not happen. Also, cookie timeout.
[23:27.550 --> 23:30.550]  Cookies should not be valid for an extended period of time. You know, time them out after
[23:30.550 --> 23:36.230]  every 24 hours, no sense putting a validated cookie out there that's infinitely usable.
[23:37.530 --> 23:43.210]  Now, how do you increase cookie security? Tie cookie authentication credentials to an
[23:43.210 --> 23:47.930]  IP address. However, again, this is going to, you know, this is going to be tricky for
[23:48.010 --> 23:54.170]  a lot of the AOL users and a lot of the SSL users. However, if you're on a small business
[23:54.170 --> 23:58.270]  internet, maybe, you know, a few hundred people, you can tie the cookie to an IP address or
[23:58.270 --> 24:02.410]  the authentication credential to an IP address without worry. You have to know your users.
[24:03.490 --> 24:08.070]  If you're servicing the entire web, use a portion of the IP address, it's better than
[24:08.070 --> 24:13.610]  nothing, okay? Now, this is an experimental security practice we've been working on, we've
[24:13.610 --> 24:17.550]  seen other people try to work on it. They've had mixed results, so your mileage may vary.
[24:17.870 --> 24:22.870]  You can actually add salt to your cookie authentication credentials by hashing in, like, an IE or
[24:22.990 --> 24:26.770]  a Netscape user agent. It gives you a lot of salt. It gives you, like, system type,
[24:26.770 --> 24:30.830]  it gives you browser version, things of that nature. So if you're tying it to an IP address,
[24:30.830 --> 24:36.290]  the user agent, a stolen cookie moved is going to have a lot harder time being used by another
[24:36.290 --> 24:43.590]  person. It's the basic trick. It's not limited to user agent and accept language. Any
[24:43.590 --> 24:47.110]  header that stays constant within a browser can be used. So, again, you have to know your
[24:47.110 --> 24:54.820]  users, you know, sniff the wire, look at your logs, and see what's going on. Further authentication
[24:54.820 --> 25:12.560]  credentials. Yes. Oh, sure. Yes, it is. He said, basically, user agent and accept language
[25:12.560 --> 25:17.160]  is spoofable. Yes, it is. However, if the user, let's say a legitimate user is logged
[25:17.160 --> 25:23.060]  in, okay, the user agent and the accept language came over from the user, it's hashed up, MD5,
[25:23.060 --> 25:27.740]  SHA1, whatever you want, with their password, wherever you want to do it. If somebody were
[25:27.740 --> 25:32.780]  to compromise that cookie, they have no idea what that other user had or submitted to begin
[25:32.780 --> 25:57.340]  with and they're not going to be able to reverse it if you use strong crypto mechanisms. The
[25:57.340 --> 26:08.500]  question was, if he logs in from home and you log in from work, there might be conflict? Sure. Oh,
[26:08.500 --> 26:11.840]  you're going to have to have logout mechanisms for that. If you stay logged in, you're going to
[26:11.840 --> 26:19.940]  have trouble. You should provide logout mechanisms. Like I said, the session should not last forever.
[26:19.940 --> 26:24.060]  There should be timeout. He asked about, you know, what if he upgrades his browser? Well,
[26:24.060 --> 26:33.000]  the session cookie should not last forever. Right, so, I'm sorry, I missed that one. Yes,
[26:33.000 --> 26:46.250]  please. Right, basically he said, if they can get the cookie, why can't they get the user agent?
[26:46.410 --> 26:52.290]  Basically because, you can in JavaScript, but it's not foolproof. You know, let me just state
[26:52.290 --> 26:55.890]  that. This is not foolproof. It's just increased. The level of skill of the attacker is going to
[26:55.890 --> 27:13.580]  be a lot greater than your average person. Yes, please. Could you stand up, please? I'm like a
[27:13.580 --> 27:22.160]  MAC address. All right, you could do that, but then, you know, you have key sharing. He basically
[27:22.160 --> 27:29.300]  said, yeah, you can solve it on the server side, but again, we're not going to get to that level
[27:29.300 --> 27:33.800]  yet. But again, this is not foolproof, but however, it is a lot better than a lot of things
[27:33.800 --> 27:38.540]  where you can move a cookie from one computer over to another and clone that user. I mean,
[27:38.540 --> 27:44.420]  imagine you can pop into any, you know, financial transaction, steal a cookie, and then you're them.
[27:44.620 --> 27:48.320]  So basically, if you're just hashing in a little bit more data, it's going to be that much harder
[27:48.320 --> 27:56.560]  for a person doing it. This is a new paper that came up from some people at MIT. It gives a lot
[27:57.120 --> 28:02.160]  of... it's one main reason why we didn't go over different cookie authentication mechanisms. They
[28:02.160 --> 28:07.940]  did an excellent job and pointed out some very good mechanisms that a lot of major sites are
[28:07.940 --> 28:17.700]  using. So if you have need, go check it out. Session tickets and passwording. A lot of times,
[28:17.700 --> 28:21.340]  when you're getting data from a web form or something from a user, you want to make sure
[28:21.340 --> 28:26.540]  it's not tampered with. You know, you can use SSL for that and has not been sent fraudulently on
[28:26.540 --> 28:32.960]  the behalf of a user. For instance, like a CGI action to delete a database or something. You
[28:32.960 --> 28:38.580]  want to make sure that the user sending that actually did that purposely. So how do you do
[28:38.580 --> 28:45.320]  that? Well, if the CGI is performing a particular critical action, have them reconfirm their
[28:45.320 --> 28:51.180]  password. It's a real simple step. It buys you a lot of security. Have a yes or no button. Very
[28:51.180 --> 28:56.400]  simple again. Yes, I did want to delete my entire domain off this web server. Instead of, like,
[28:56.400 --> 29:01.660]  just basically sending a get request, they have to say yes or no. Very simple stuff. Entirely
[29:02.300 --> 29:08.960]  underused out there. I can't stress the importance enough of this. Basically, if you know a user is
[29:08.960 --> 29:14.320]  logged into, like, you know, any kind of service, any kind of message board, you send it to a chat
[29:14.320 --> 29:19.520]  room or a message board administrator, you send them a personal message or some kind of message
[29:19.520 --> 29:24.340]  and they read it, guess what? You can perform any action as them, at least for the moment. So
[29:24.340 --> 29:30.920]  basically, if it's a critical action, say yes or no or a new password. Referrer checking. This is
[29:30.920 --> 29:36.520]  something I don't recommend. This is entirely spoofable. However, if you know your users, this
[29:36.520 --> 29:39.920]  can be done. Like, for instance, on a business internet, we're just going to kind of gloss over
[29:39.920 --> 29:45.360]  this. But as far as referrers are concerned, don't trust client-side data. Okay, that's very
[29:45.360 --> 29:53.400]  important. Get versus post. A lot of times the same results can be had from a CGI by using gets
[29:53.400 --> 30:00.000]  and posts. If a form is, if the legitimate form is supposed to be being sent as a post request,
[30:00.000 --> 30:04.780]  accept only post requests. This stops a lot of automated scripting because basically because
[30:04.780 --> 30:10.060]  if you send like a cross-scripting exploit to someone, it's, and it sends like a get request,
[30:10.060 --> 30:13.540]  it's going to, it sends a get request and not a post. So that way it buys you a little bit
[30:13.540 --> 30:22.100]  more security by checking the request method. Off-domain hosting of user data. If you can't
[30:22.100 --> 30:26.360]  control or if you don't want to control user data, host it on a different domain. Basically
[30:26.360 --> 30:31.580]  if you're using, if you're hosting on like acme.com, host user data on acme.net. It might
[30:31.580 --> 30:38.900]  be a little painful, however, it does buy you a lot of security. Now, the parts that I find most
[30:38.900 --> 30:43.540]  interesting and most fun to screw around with. Filter bypassing. JavaScript is a cockroach.
[30:43.540 --> 30:49.540]  It's hard to stamp out. There are all kinds of, you know, input filters in web applications that
[30:49.540 --> 30:54.080]  try to prevent HTML and JavaScript from entering into a system. So this next section is basically
[30:54.080 --> 31:00.020]  how do you audit, how do you beat HTML filters. A lot of data inside. Again, you don't have to
[31:00.020 --> 31:08.100]  scribble it all down. It'll be available later. So basically what these exploits or methods show
[31:08.100 --> 31:12.740]  is how to do, you know, cross-scripting exploits, browser hijacking. We've already kind of glossed
[31:12.740 --> 31:18.320]  over how you can do some of those attacks. These are how to execute them. Testing the filters,
[31:18.320 --> 31:22.400]  first of all, we're going to start real simple and work our way up pretty fast. If you're auditing your
[31:22.400 --> 31:27.080]  own application, send as much HTML to it as you can, every single tag in the arsenal, with every
[31:27.080 --> 31:32.600]  attribute you can find, and view the output and see what changed. Okay, it goes a long way towards
[31:32.600 --> 31:40.620]  auditing. The script tag, you know, still very simple. Script tag, you can enter any JavaScript
[31:40.620 --> 31:45.400]  expression, including document.cookie. This is important here. Anytime you can get like an alert
[31:45.400 --> 31:53.190]  to show up in an environment, basically that's cause for alarm. Sourcing JavaScript protocol.
[31:53.330 --> 31:58.270]  Basically, in Netscape, I don't think it works in IE, I have to double check,
[31:58.270 --> 32:02.750]  the JavaScript protocol, and after the colon, you can execute any expression that you want.
[32:03.110 --> 32:09.430]  The image that's source equals. Any tag that you can source has that problem. So you're going to
[32:09.430 --> 32:16.750]  have to substitute the JavaScript string inside a source attribute. You know, just change it a
[32:16.750 --> 32:20.950]  little bit. You can use the underscore, or you can erase a letter, or put a hyphen in it, whatever
[32:20.950 --> 32:27.830]  you want, but you have to do something with it. So, again, any tag that has a source attribute,
[32:27.830 --> 32:31.630]  you're going to have to put your pattern matching in and search for all the source attributes for
[32:31.630 --> 32:36.790]  this type of thing. Even worse, LiveScript and Mocha achieved the same results in Netscape,
[32:36.790 --> 32:41.170]  old Netscape codename throwback that still works to execute JavaScript. What you're going to find
[32:41.170 --> 32:47.130]  in this, HTML is so loose that you can actually just totally manipulate and warp everything,
[32:47.130 --> 32:51.870]  and things still execute, which is one of the good things about XML that it'll help out with.
[32:52.670 --> 32:57.130]  Another one, the line breaks. Same thing, JavaScript and alert. Line break it,
[32:57.130 --> 33:02.930]  and it'll probably beat the pattern match. Basically, if you visualize the regular expression,
[33:02.930 --> 33:07.930]  it's going to be trying to match JavaScript as a string inside a source. However, if there's a
[33:07.930 --> 33:10.890]  carriage return in it, it's not going to match, and it's just going to blow up, and that will
[33:10.890 --> 33:17.010]  still execute. Oh, tabs, new lines, carriage returns in all whitespace count for this type
[33:17.010 --> 33:25.830]  of thing. HTML entities, kind of a derivative of the previous one, using HTML entities to put
[33:25.830 --> 33:31.850]  whitespace into the strings. This works, as well as the decimal, the hex, and multiple zeros in
[33:31.850 --> 33:39.720]  front will all execute JavaScript expressions inside any source attribute. I call this and
[33:39.720 --> 33:43.320]  curly. I don't know where this came from. I kind of saw it online. I was kind of screwing
[33:43.320 --> 33:44.620]  around with it, but the syntax is very...
